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Abstract 


A  single  platform,  or  ownship,  typically  has  many  available  sensor  resources.  These 
sensors  provide  data  to  software  applications  that  form  tracks,  fuse  tracks  and  display 
results.  Other  information  may  also  be  fused  including  remote  source  data  such  as  that 
from  Link  1 1  transmissions,  or  a  recognized  maritime  picture.  The  management  of 
this  multitude  of  potentially  replicate  data  is  an  important  function  of  the  ownship 
tactical  data  system.  In  this  report,  three  developments  are  assessed  for  potential  use  in 
the  tactical  data  management  process;  the  Land  Command  and  Control  Information 
Exchange  Data  Model,  the  Maritime  Information  Sharing  Technology,  and  Web 
Services.  This  assessment  indicates  that  none  are  presently  capable  of  supporting 
tactical  data  management  on  ownship. 


Resume 


Une  plate-forme  unique,  ou  navire  observateur,  possede  en  general  de  nombreux 
capteurs.  Ces  ressources  foumissent  des  donnees  a  des  applications  logicielles  qui 
produisent  des  pistes,  les  fusionnent  et  affichent  les  resultats.  D’autres  informations 
peuvent  aussi  etre  fusionnees,  y  compris  des  donnees  de  sources  eloignees,  p.  ex.  des 
donnees  provenant  de  transmissions  Link  1 1  ou  d’une  image  maritime  reconnue.  La 
gestion  de  cette  multitude  de  donnees  susceptibles  d’etre  repliquees  est  une  function 
importante  du  systeme  de  donnees  tactiques  du  navire  observateur.  Dans  le  present 
rapport,  trois  developpements  sont  evalues  du  point  de  vue  de  leur  utilisation  possible 
dans  le  processus  de  gestion  des  donnees  tactiques,  soit :  le  modele  de  donnees 
d'echange  d'information  de  commandement  et  de  controle  (Terre),  la  technologic  de 
partage  d'information  maritime  et  les  services  Web.  L’evaluation  indique  qu’aucune  de 
ces  technologies  ne  pent  actuellement  repondre  aux  besoins  de  la  gestion  de  donnees 
tactiques  a  bord  d’un  navire  observateur. 
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Executive  summary 


Introduction 

Tactical  data  may  be  considered  the  data  originating  from  a  multitude  of  sensors, 
tracker  applications,  and  track  fusion  applications,  all  of  which  operate  on  a  single 
platform  called  ownship.  The  organization  of  these  tactical  data  is  important  for  the 
sharing  of  data  among  the  ownship  applications,  and  also  potentially  for  the  sharing  of 
data  between  platforms. 

Existing  technologies  need  to  be  assessed  in  terms  of  their  applicability  to  the  storage 
and  management  of  the  ownship  tactical  data.  Three  technologies  are  considered  in 
this  report,  those  being  the  Land  Command  and  Control  Information  Exchange  Data 
Model,  the  Maritime  Information  Sharing  Technology  and  Web  Services.  This  report 
assesses  these  three  technologies  in  terms  of  vendor  availability,  cost,  openness, 
maturity  and  evolution  potential. 

Principal  Results 

The  three  technologies  are  all  noted  to  be  effective  in  the  intended  developmental 
scope.  However,  none  are  immediately  appropriate  for  use  as  a  data  support  function 
for  tactical  systems. 

Significance  of  Results 

Tactical  systems  on  a  single  platform  require  a  data  support  function.  This  function 
needs  to  be  capable  of  supporting  a  multitude  of  sensors  and  processing  applications 
for  the  management  of  contacts  and  tracks.  Recognising  that  the  three  investigated 
technologies  do  not  support  this  function  is  an  important  step  in  the  developmental 
process  for  onboard  combat  systems. 

Future  Plans 

The  results  of  this  report  will  be  incorporated  into  a  larger  United  Kingdom  (UK) 
effort  that  is  investigating  the  applicability  of  these  and  other  technologies  to  support 
the  data  needs  of  a  platform  combat  system.  If  the  investigation  does  not  identify  a 
suitable  technology,  a  functional  requirements  and  data  modelling  effort  will  be 
undertaken  to  develop  the  necessary  structure  to  support  a  combat  system.  Such  an 
effort  would  likely  be  a  collaborative  UK-Canada  development. 
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Sommaire 


Introduction 

Les  donnees  tactiques  peuvent  etre  considerees  comme  les  donnees  provenant  d’une 
multitude  de  capteurs,  d’ applications  de  poursuite  et  d’ applications  de  fusion  de  pistes, 
qui  sont  tons  exploites  a  bord  d’une  plate-forme  unique  appelee  «  navire  observateur  ». 
L’ organisation  de  ces  donnees  tactiques  est  importante  pour  le  partage  de  donnees 
entre  les  applications  du  navire  observateur,  et  peut-etre  aussi  pour  le  partage  de 
donnees  entre  les  plates-formes. 

II  est  necessaire  d’evaluer  les  technologies  existantes  du  point  de  vue  de  leur 
applicablite  au  stockage  et  a  la  gestion  de  donnees  tactiques  de  navire  observateur. 
Trois  technologies  sont  examinees  dans  le  rapport,  soit :  le  modele  de  donnees 
d'echange  d'information  de  commandement  et  de  controle  (Terre),  la  technologic  de 
partage  d'information  maritime  et  les  services  Web.  Le  rapport  evalue  ces  trois 
technologies  du  points  de  vue  de  leur  disponibilite  aupres  des  foumisseurs,  de  leur 
cout,  de  leur  ouverture,  de  leur  maturite  et  de  leur  potentiel  d’ evolution. 

Principaux  resultats 

Les  trois  technologies  se  sont  averees  efficaces  dans  le  cadre  de  developpement 
projete.  Toutefois,  aucune  n’est  immediatement  utilisable  comme  fonction  de  support 
de  donnees  pour  les  systemes  tactiques. 

Portee  des  resultats 

Les  systemes  tactiques  sur  plate-forme  unique  necessitent  une  fonction  de  support  de 
donnees.  Cette  fonction  doit  permettre  Texploitation  d’une  multitude  de  capteurs  et 
d’ applications  de  traitement  aux  fins  de  la  gestion  de  contacts  et  de  pistes.  Le  fait  de 
constater  que  les  trois  technologies  etudiees  n’assurent  pas  cette  fonction  marque  une 
etape  importante  dans  le  processus  de  developpement  des  systemes  de  combat 
embarques. 

Recherches  futures 

Les  resultats  du  rapport  seront  integres  a  des  travaux  de  plus  grande  envergure  du 
Royaume-Uni  (R.-U.)  portant  sur  I’applicabilite  de  ces  technologies  et  d’autres 
techniques  destinees  a  repondre  aux  besoins  de  donnees  d’un  systeme  de  combat 
installe  sur  plate-forme.  Si  I’etude  n’identifie  pas  une  technologic  satisfaisante,  un 
effort  de  modelisation  des  exigences  fonctionnelles  et  des  donnees  sera  entrepris  afin 
d’elaborer  la  structure  necessaire  pour  les  besoins  d’un  systeme  de  combat.  Cet  effort 
sera  probablement  mene  en  collaboration  par  le  R.-U.  et  le  Canada. 
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1.  Introduction 


A  single  naval  platform  typically  has  many  sensor  resources.  These  sensors  generate 
data  related  to  location  and  states  of  remote  platforms.  However,  having  many  sensors 
at  the  disposal  of  the  platform  can  create  challenges  related  to  the  management  of  the 
data  emanating  from  these  sensors. 

Consider  the  situation  of  multiple  sonar  sensors,  all  operating  and  in  some  fashion 
analysing  the  acoustic  environment.  Suppose  the  majority  of  sensors  are  located  on  a 
submarine.  Some  may  not  physically  be  on  the  submarine,  for  example,  deployable 
sensors  that  are  dropped  from  the  submarine  to  the  sea  bottom. 

Each  sensor  consists  of  the  hardware  that  makes  up  the  sensor,  and  application 
software  that  inputs  the  data  stream  and  automatically  creates  tracks  based  on  the 
stream.  In  this  context,  tracks  may  be  considered  consistent  and  repeated  contact  with 
something  that  forms  an  identifiable  series  or  “track”  for  the  object  (a  track  in  acoustic 
space  rather  than  the  well  known  track  on  the  ground).  Many  of  these  applications, 
called  trackers,  use  the  input  stream  from  a  single  sensor.  Each  tracker  would  use  a 
different  algorithm  for  track  generation,  thus  providing  multiple  possibilities  for  the 
tracks  (see  Figure  1). 

However,  the  situation  quickly  becomes  complicated  because  a  single  real-world 
object  may  be  responsible  for  one  or  more  tracks  generated  from  one  or  more  tracker 
applications.  In  this  case,  tracks  need  to  be  grouped  using  grouper  applications,  to 
form  a  single  master  track  based  on  a  collection  of  primitive  individual  tracks. 

There  may  also  be  many  grouper  applications,  again  each  being  distinct  because  of  the 
algorithm.  Thus,  multiple  grouper  applications  will  provide  multiple  possible 
solutions  to  the  grouping  problem. 

Each  grouper  application  is  creating  a  unique  group  of  tracks  that  hopefully  represents 
a  real-world  object.  However,  other  classifier  applications  examine  the  grouped  track 
and  attempt  to  class  the  track  as  a  particular  object  class  (e.g.,  a  ship,  a  marine 
mammal).  Again,  there  may  be  multiple  classifiers  executing,  each  unique  because  of 
the  underlying  algorithm  or  because  of  the  algorithm’s  use  of  the  input  data. 

Of  course  the  information  available  to  the  submarine  may  also  originate  from  other 
sources.  For  example,  incoming  information  may  be  obtained  via  Link  1 1  or  from  the 
Recognized  Maritime  Picture  (RMP).  This  information  must  also  be  accessible  to  the 
applications  and  potentially  fused  with  the  submarine  sensor  data. 

In  terms  of  traditional  data  modelling,  which  utilizes  entity-relationship  modelling 
techniques,  the  need  to  organise  and  manage  the  multiple  outcomes  of  the  situation 
essentially  decomposes  to  multiple  many-to-many  table  relationships.  This  is  the 
primary  complication  in  the  data  modelling  exercise  associated  with  this  situation. 
However,  before  considering  the  details  of  any  data  modelling  exercise,  we  must  first 
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assess  existing  technologies  or  developments  that  may  already  deal  with  this  data 
management  problem. 


Contacts 


Tracker 
Application  1 


X 

Tracker 

Application 

K 

Grouper 
Application  A 


Grouper 
Application  B 


Figure  1.  Contacts  are  shown  at  the  left,  as  a  sequence  ofX  marks.  Tracker  application  1  produces 
two  tracks  based  on  the  contacts  (indicated  by  blue  and  black  lines),  while  tracker 
application  2  produces  a  different  set  of  tracks.  Grouper  application  A  and  B  both  act  on 
the  output  of  Tracker  Application  1  producing  two  different  groupings.  Grouper  A  and  B 
may  also  be  acting  on  Tracker  Application  2  output  (not  shown). 


The  following  brief  report  outlines  three  potential  technologies  that  may  be  of  use  in 
such  a  situation.  This  report,  which  is  a  contribution  to  a  larger  UK  effort  assessing 
similar  technologies,  considers  the  Land  Command  and  Control  Information  Exchange 
Data  Model  (LC2IEDM),  the  Maritime  Information  Sharing  Technology  (MIST),  and 
Web  Services. 

All  three  technologies  are  based  to  some  extent  on  the  principle  of  shared  resources. 
The  LC2IEDM  was  developed  for  the  sharing  of  operational  data  that  supports 
situational  awareness  in  a  battlespace.  LC2IEDM  attempts  to  identify  the  objects 
associated  with  the  battlespace,  characteristics  of  these  objects,  and  actions,  which 
collectively  are  items  that  contribute  to  the  context  of  the  battlespace. 

The  MIST  system  was  developed  for  the  operational  sharing  of  contact  data 
originating  from  sonar.  MIST  is  actually  a  system,  with  a  developed  database  and 
support  services.  These  services  utilize  web  service  technologies. 
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Finally,  Web  Services  are  a  technical  specification  for  the  creation  of  online  services. 
A  service  can  be  considered  an  online  resource  that  remote  applications  can  access. 
These  services  typically  perform  very  specific  functions.  For  example,  a  service  may 
access  a  currency  exchange  system  and  provide  online  currency  conversion. 

Each  of  the  three  technologies  is  assessed  by  first  providing  a  brief  description 
followed  by  an  examination  of  vendor  support,  cost,  openness,  maturity  and  the 
potential  for  evolution.  Vendor  support  considers  the  commercial  support  of  the 
technology.  Cost  qualitatively  considers  the  costs  associated  with  developing  the 
technology  for  a  tactical  data  management  scenario.  Openness  examines  the 
accessibility  of  the  technology  software  or  related  specifications.  Maturity  examines 
the  state  of  the  technology  in  terms  of  its  past  development  time.  Evolution  attempts 
to  forecast  the  potential  of  the  technology  for  continued  development  and 
improvement.  Finally,  an  overall  assessment  of  the  technology’s  usefulness  from  a 
tactical  data  management  perspective  is  made. 
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2.  Land  Command  and  Control  Information 
Exchange  Data  Model 

2.1  Description 

The  Land  Command  and  Control  Information  Exchange  Data  Model  (LC2IEDM)  [1] 
is  a  development  that  originated  in  the  Multilateral  Interoperability  Program  (MIP)  [2]. 
MIP  is  not  a  formal  program,  but  rather  is  a  voluntary  activity  of  supporting  nations 
(see  Annex  1).  The  aim  of  the  MIP  is  ‘‘to  achieve  international  interoperability  of 
Command  and  Control  Information  Systems  (C2IS)  at  all  levels  from  corps  to 
battalion,  or  the  lowest  appropriate  level,  in  order  to  support  multinational  (including 
NATO^),  combined  and  joint  operations  and  the  advancement  of  digitization  in  the 
international  arena""  [3]. 

The  LC2IEDM  has  recently  been  superseded  by  the  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM)  [3].  The  MIP  committee  approved 
C2IEDM  Edition  6  in  November  2003.  The  data  model  specification  and  supporting 
documentation  was  made  available  on  the  MIP  web  site  [2]  in  the  spring  of  2004.  The 
C2IEDM  is  based  on  the  LC2IEDM,  with  additional  tables  for  navy  and  air  force 
specific  information.  There  has  also  been  additional  work  on  clarifying  some  table 
descriptions  and  content  to  make  a  more  generic  structure.  However,  this  report 
describes  the  LC2IEDM  because  the  modifications  that  resulted  in  C2IEDM  are  still 
being  examined  and  understood.  However,  preliminary  examination  shows  that  the 
navy-specific  additions  do  not  impact  the  assessment  contained  in  this  report. 

The  consideration  of  the  LC2IEDM  must  first  recognize  several  important  terms  that 
relate  the  LC2IEDM  to  the  larger  system.  LC2IEDM  is  a  data  model,  and  as  such,  is 
not  a  system  but  rather  a  structured  set  of  definitions  and  relationships  that  pertain  to  a 
database.  There  is  a  larger  system  defined  with  the  LC2IEDM  including  such  things  as 
an  automated  replication  mechanism  (ARM)  [4].  The  ARM  specification  details  the 
replication  of  data  between  instances  of  the  Land  Command  and  Control  database 
(LC2DB,  note  that  for  clarity  the  database  is  being  distinguished  from  the  data  model). 
Several  countries  including  Canada  have  implemented  the  ARM  specification. 

The  Operational  Context  Exchange  Service  (OCXS,  [5])  is  a  Java  software  suite  that 
has  been  developed  by  the  United  States  (US)  Naval  Undersea  Warfare  Center 
(NUWC)  and  is  used  to  communicate  to  and  from  the  LC2DB.  The  suite  was  designed 
to  act  as  a  bridge  between  the  LC2DB  and  outside  applications.  Note  the  difference 
between  the  OCXS  and  the  ARM.  The  ARM  deals  with  database  instance-to-instance 
replication,  while  the  OCXS  deals  with  application-to-database  communication.  These 
components  will  be  briefly  described. 


^  NATO  -  North  Atlantic  Treaty  Organisation 
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The  OCXS  provides  a  data  path  between  outside  applications  and  the  LC2DB.  OCXS 
places  data  into  the  LC2DB  using  the  physical  model  name  set  expressed  in  extensible 
markup  language  (XML)  [6,  7].  All  relationships  within  the  LC2DB  are  dealt  with 
implicitly  from  the  data  file.  OCXS  does  not  deal  with  any  database  relationships. 
This  means  that  the  input  XML  document  must  load  the  LC2DB  tables  without 
violating  any  formal  relationships  as  specified  in  the  LC2IEDM.  A  schematic  of  an 
OCXS  message  object  placing  data  into  the  LC2DB  is  shown  in  Figure  2. 

OCXS  also  deals  with  output  from  the  LC2DB.  OCXS  can  request  information  from 
the  database,  with  the  information  being  made  available  to  the  user  as  a  physical  XML 
tag  set. 


Client  Tier  (Application  Server)  Database  Tier 

Figure  2.  The  OCXS  uses  input  message  objects  in  XML,  to  construct  SQL  input  statements  that  are 
used  to  place  data  into  the  LC2DB.  Reproduced  from  [7]. 


The  ARM  specification  includes  the  functional  requirements  of  the  data  replication 
between  LC2DB  instances  (Figure  3).  The  ARM  consists  of  a  replication  database  that 
consists  of  about  40  tables.  These  tables  are  used  to  coordinate  the  transport  of  data 
from  one  LC2DB  instance  to  another.  In  essence,  the  ARM  database  identifies  nodes 
in  the  LC2DB  network,  protocols  between  the  nodes,  data  contracts  between  the  nodes, 
and  the  actual  data  contained  in  the  LC2DB  instance.  In  terms  of  the  data,  the  ARM 
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database  holds  information  on  the  data  value,  and  the  table  and  column  where  that  data 
value  resides  in  the  LC2DB  instance  providing  the  data. 

The  LC2IEDM  specifies  the  entity/relationship  model  that  forms  the  central  structure 
of  the  larger  system.  The  LC2IEDM  consists  of  about  200  tables  and  supporting 
relationships.  The  main  model  concepts  deal  with  objects  that  exist  at  described 
locations.  The  model  allows  the  objects  to  have  described  capabilities,  which  leads  to 
the  objects  conducting  certain  actions  on  targets.  The  objects  may  also  operate  in  a 
certain  context  which  may  be  defined  by  the  reporting  of  associated  objects, 
capabilities,  actions,  etc.  or  through  the  actions  of  the  objects  relative  to  described 
rules-of-engagement. 


Network 

Connection 


O 


ARM  DB 


ARM  DB 


Figure  3.  The  ARM  consists  of  a  database  specifically  for  managing  the  data  replication  between  two 
LC2DB  instances. 


2.2  Vendors 

The  LC2IEDM  development  is  a  result  of  multinational  collaboration,  under  the 
auspices  of  the  MIP.  Large  commercial  software  vendors  do  not  directly  support  the 
LC2IEDM  development.  However,  there  are  activities  to  train  military  contractors  in 
the  LC2IEDM.  Individual  military  research  laboratories  are  also  producing  software 
that  supports  LC2IEDM.  OCXS  is  an  example  of  such  software. 
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2.3  Cost 


The  data  model  and  documentation  is  free  of  charge.  The  creation  scripts  are  available 
for  the  Oracle  database  management  system  (DBMS).  There  is  a  free  version  of  the 
Oracle  DBMS  available  for  download  [8],  and  this  is  quite  adequate  for  basic  research. 
However,  any  implementation  would  likely  require  the  purchased  Oracle  DBMS 
product.  The  small  business  version  of  the  Oracle  DBMS  is  about  $700  US. 

Implementation  of  the  ARM  specification  would  be  potentially  costly.  However,  both 
Canada  and  the  UK  have  ARM  implementations.  These  may  be  available  through 
national  contacts. 

There  are  no  applications  that  are  standard  with  the  LC2IEDM  system.  Again, 
individual  organizations  are  developing  these  applications,  which  may  be  available 
through  national  contacts. 


2.4  Openness 

The  data  model  description  is  available  as  entity-relationship  diagrams  (for  example 
diagrams  see  references  6  and  7)  produced  from  ERwin™  [9]  software.  The  diagrams 
are  freely  available  from  the  MIP  web  site  [2].  The  data  model  itself  is  open,  as  the 
generation  scripts  and  structures  are  also  available. 

The  openness  of  individual  software  developments  to  support  the  database  will  depend 
on  the  specific  development.  For  example,  the  ARM  implementations  may  be 
available  from  national  contacts. 


2.5  Maturity 

The  data  model  has  been  in  the  conceptual  and  development  phase  for  about  20  years. 
As  such,  from  the  perspective  of  army  operations,  the  model  is  quite  mature.  The 
supporting  applications  for  the  model  are  presently  being  developed  and  thus  are  not  as 
mature. 


2.6  Evolution  Potential 

This  model  has  enormous  support  in  the  army,  both  in  terms  of  human  and  fiscal 
resources.  Although  unproven,  it  is  expected  that  the  model  is  capable  of  dealing  with 
high-level  objects  for  the  navy.  In  this  regard,  the  model  has  great  potential. 
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The  model  has  already  gone  through  various  stages  of  evolution.  Initially  the  model 
was  known  as  the  Generic  Hub  (GH)  and  then  the  LC2IEDM.  More  recently,  the 
model  has  evolved  to  account  for  air  force  and  navy  requirements  and  has  been 
renamed  to  the  C2IEDM. 

The  model  is  also  being  incorporated  into  the  NATO  Technical  Architecture.  Current 
plans  are  underway  to  define  the  LC2IEDM  as  the  NATO  Reference  Model.  This 
means  the  ideas,  objects  and  structures  present  in  the  LC2IEDM  will  most  likely 
propagate  into  other  NATO  models,  which  are  built  based  on  the  Reference  Model. 
LC2IEDM  is  quickly  evolving  into  a  recognized  standard  for  the  sharing  of  command 
and  control  battlespace  data  and  information. 

The  MIP  is  dedicated  to  the  evolution  of  the  LC2IEDM.  In  this  regard,  MIP  has  eight 
technical  working  groups  and  one  multi-disciplinary  working  group  dedicated  to  tasks 
such  as  system  engineering  and  architecture,  data  modelling,  test  and  evaluation,  etc. 
These  groups  are  continually  working  for  the  improvement  of  the  model. 

It  should  be  noted  that  the  LC2IEDM  system  is  also  extensible.  The  system  allows  the 
creation  of  tables  for  use  within  a  specific  user  group.  This  allows,  for  example,  a 
group  of  national  assets  to  create  data  structures  important  for  national  objectives,  and 
to  share  the  data  within  these  tables  among  themselves. 

Overall,  the  evolution  potential  of  LC2IEDM  is  considered  high.  However,  it  is 
unlikely  that  LC2IEDM  will  evolve  into  a  solution  for  tactical  data  management.  This 
is  because  the  tactical  data  management  problem  is  not  a  C2IS  issue.  The  MIP  aim  [2] 
is  to  specifically  address  C2IS  interoperability.  As  well,  NATO  solutions  are  directed 
at  the  operational  and  strategic  level,  while  national  partners  provide  tactical  level 
support  [10]. 


2.7  Overall  Assessment  from  a  Tactical  Data  Perspective 

The  LC2IEDM  and  supporting  specifications  were  designed  to  describe  the  shared 
information  requirements  of  command  and  control  information  systems.  As  such,  the 
model  was  not  intended  as  a  tactical  data  management  solution.  The  challenges  of 
tactical  data  management,  as  described  in  the  Introduction,  cannot  be  addressed  by  the 
present  LC2IEDM. 
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3.  Maritime  Information  Sharing  Technology 

. W . W.«€.... 


3.1  Description 

The  MIST  system  consists  of  all  developed  components  required  for  a  functional 
system.  MIST  includes  a  DBMS,  client  and  server  software,  messaging  between  the 
client  and  server,  and  a  database. 

The  MIST  database  is  implemented  in  an  open  source  DBMS  named  PostGreSQL. 
PostGreSQL  had  its  beginnings  at  the  University  of  California,  Berkley,  in  1986  [11]. 
The  development  of  PostGreSQL  has  since  evolved  into  a  Global  Development  Group, 
consisting  of  companies  and  individuals  around  the  world. 

The  MIST  server  utilizes  open  source  software  developed  at  The  Apache  Software 
Foundation  (ASF,  formerly  known  as  the  Apache  Group).  ASF  is  an  open  source 
development  organization  [12]  consisting  of  a  community  of  developers  and  users. 

One  ASF  development  is  named  Tomcat,  a  sub-project  under  the  Apache  Jakarta 
project. 

Tomcat  provides  the  means  to  execute  a  service  that  is  provided  on  the  server.  Tomcat 
listens  for  incoming  requests  that  are  in  the  form  of  messages.  A  service  is  executed 
when  an  appropriate  message  is  received. 

The  messaging  used  in  the  MIST  system  is  based  on  the  Simple  Object  Access 
Protocol  (SOAP).  SOAP  [13]  is  a  World  Wide  Web  Consortium  (W3C)  Web  Services 
message  specification.  One  implementation  of  the  W3C  specification  has  been 
developed  under  the  Apache  Web  Services  Project. 

SOAP  is  described  as  a  lightweight  XML-based  message  protocol  used  in  a  distributed 
environment.  In  the  MIST  implementation,  SOAP  is  used  as  the  message  protocol  to 
request  actions  and  receive  responses  from  the  MIST  server.  For  an  introduction  to 
XML-based  languages,  see  [14]. 

The  MIST  server  [15]  provides  access  to  services  using  Tomcat.  As  noted  above. 
Tomcat  listens  for  incoming  requests.  SOAP  provides  the  messaging  language  for  the 
request.  Thus,  SOAP  is  the  language  being  used  between  the  client  (performing  the 
request)  and  Tomcat  (receiving  the  request).  SOAP  is  also  the  messaging  protocol 
from  the  server  back  to  the  client  (Figure  4). 

The  MIST  client  and  server  software  [16]  also  consists  of  developed  Java  code.  This 
software  represents  the  services  provided  by  the  server  and  the  software  for  requesting 
the  services,  which  is  on  the  client.  At  present,  the  MIST  system  supports  services  for 
initializing  the  database,  adding  and  removing  contacts  from  the  database,  and 
retrieving  contacts  and  contact  history  from  the  database. 
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Figure  4. 


Request  to 

execute 

service 
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service 


Requesting  software  sends  the  request  via  a  SOAP  message  to  a  server  running  Tomcat 
Tomcat  sends  the  request  to  the  service,  which  executes  and  sends  a  response  back  to 
Tomcat.  Tomcat  generates  a  return  SOAP  message  and  sends  this  to  the  requesting 
software. 


The  MIST  database  is  a  two-table  structure  with  no  formal  relationships.  One  table 
maintains  a  list  of  contacts,  while  the  second  table  maintains  the  details  of  the  contact 
information.  The  contact  information  consists  of  information  on  the  sensor  used  to 
determine  the  contact,  the  position  of  the  contact  (e.g.,  latitude,  longitude,  course, 
speed,  bearing  and  range),  contact  identification  information  (e.g.,  track  number, 
country,  domain  of  operation,  unique  identifiers  and  threat  level),  time  stamps,  and 
security  information. 

The  MIST  system  may  be  considered  a  centralized  data  system.  However,  the 
implementation  can  be  as  a  set  of  clusters.  Each  cluster  would  represent  the  MIST 
client-server  model,  where  multiple  clients  are  connected  to  the  central  server. 
Clusters  can  then  be  connected  to  a  higher-level  central  server,  thus  developing  a 
tree-type  architecture. 
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3.2  Vendors 


There  is  no  commercial  vendor  support  for  this  system.  At  present,  the  system  is 
purely  a  research  tool  and  as  such,  is  only  supported  by  the  two  primary  development 
labs,  NUWC  and  the  UK  Defence  Science  and  Technology  Laboratory  (DSTL). 


3.3  Cost 

This  system  is  freely  available  to  countries  participating  in  The  Technical  Cooperation 
Program  (TTCP)  and  has  been  released  to  TTCP  Maritime  Systems  Group.  Tomcat 
and  PostGreSQL  are  also  freely  available  from  the  referenced  websites. 


3.4  Openness 

MIST  utilizes  PostGreSQL,  an  open  source  DBMS,  and  Apache  Tomcat,  an  open 
source  servlet  container.  The  data  structure  is  also  open  to  TTCP  countries,  although 
no  formal  data  model  exists  (e.g.,  ERwin™).  The  MIST  software  that  supports  the 
SOAP  services  is  also  open  source  to  TTCP  countries. 


3.5  Maturity 

The  MIST  system  development  was  first  released  to  the  TTCP  community  in  2002.  As 
a  system,  MIST  can  be  considered  relatively  immature. 


3.6  Evolution  Potential 

MIST  is  managed  by  a  collaborative  effort  between  NUWC  and  DSTL.  MIST  has 
been  assessed  in  comparison  to  general  navy  contact  data  [6],  and  was  noted  to  contain 
many  essential  elements  in  a  contact  record.  However,  the  assessment  did  uncover 
various  areas  of  potential  improvement  for  the  MIST  system.  Unfortunately,  the  MIST 
management  does  not  appear  to  be  addressing  these  suggestions.  As  well,  there  has 
been  no  indicated  evolution  of  the  system  over  the  past  two  years.  The  evolution 
potential  of  MIST  is  considered  low. 
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3.7  Overall  Assessment  from  a  Tactical  Data  Perspective 


In  part,  MIST  was  developed  as  a  tool  for  investigating  network  sharing  of  data 
between  platforms.  The  MIST  database  deals  exclusively  with  known  contact  data. 
These  data  represent  the  output  of  the  tactical  systems  that  were  described  in  the 
Introduction.  MIST  was  not  intended  as  a  sharing  mechanism  for  tactical  data. 
Although  the  central  ideas  around  the  MIST  development  could  be  useful  for  a  tactical 
system,  MIST  in  its  present  form  does  not  meet  the  requirements  of  a  database  system 
for  managing  tactical  data. 
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4.  Web  Services 


4.1  Description 

Web  Services  is  the  term  given  to  a  collection  of  specifications  that  describe  access 
methods  to  services  over  the  web.  Web  Services  do  not  consist  of  one  thing  in 
particular,  but  rather  a  collection  of  specifications. 

Access  is  the  key  component  that  is  guiding  Web  Services.  Web  Services  are  based  on 
the  premise  that  developed  services  should  not  be  restricted  to  specific  implementation 
languages  or  hardware  used  to  provide  the  service.  Web  Services  provide  the 
developer  with  the  ability  to  separate  applications  into  functional  components,  and  to 
develop  those  components  on  different  hardware  platforms  and  different  languages. 

The  communication  between  the  components  is  provided  by  Web  Services. 

Web  Services  have  their  foundation  in  XML.  From  the  XML  development,  came  the 
three  essential  languages  that  may  collectively  be  called  Web  Services:  SOAP,  Web 
Services  Definition  Language  (WSDL)  [17]  and  Universal  Description,  Discovery  and 
Integration  (UDDI)  language  [18].  Only  SOAP  has  been  described  previously 
(Section  3.1). 

In  a  Web  Services  environment,  developers  should  not  be  developing  services  that 
already  exist.  Thus,  a  service  provided  over  the  web  needs  to  have  a  discovery 
mechanism  that  allows  the  service  to  be  found.  The  UDDI  allows  this  discovery 
mechanism  by  providing  a  searchable  listing  of  service  information.  Software  can 
search  the  UDDI  to  discover  the  services  identified  by  the  particular  listing.  This  is 
illustrated  in  Figure  5. 

Once  an  appropriate  service  is  identified,  the  client  will  want  to  execute  the  service. 

To  execute  the  service,  the  interface  requirements  must  be  known.  For  example,  the 
service  may  require  one  or  more  input  parameters.  The  WSDL  for  the  service  provides 
the  interface  specification.  This  specification  describes  the  details  of  how  to  interact 
with  the  service.  Typically,  the  WSDL  describes  a  SOAP  message  construct  for 
interacting  with  the  service.  By  constructing  and  sending  the  properly  structured 
SOAP  message,  one  can  execute  the  service  and  obtain  the  results  of  the  service. 

A  WSDL  and  SOAP  example  of  a  web  service  is  provided  in  Annex  2.  A  simple  web 
service  development  is  also  provided  in  [6]. 


DRDC  Atlantic  TM  2004-148 


13 


Request 

interface 

protocol 


Request 

service 

search 

UDDI 

Cotelogue 
of  services 

A' 

<- 

\ 

Figure  5.  A  request  is  sent  to  a  UDDI  catalogue.  The  catalogue  contains  a  listing  of  all  available 

Services  1  to  n.  Once  an  appropriate  service  is  found,  a  request  is  made  for  the  interface 
protocol  from  the  WSDL  listing  (shown  in  blue).  After  the  interface  protocol  is  obtained,  a 
request  may  be  directed  to  the  Service  using  a  SOAP  message  built  according  to  the 
interface  protocol.  This  request  would  be  similar  to  Figure  4. 


4.2  Vendors 

The  UDDI  and  WSDL  specifications  are  available  on  the  World  Wide  Web.  WSDL 
was  developed  as  part  of  the  W3C  Web  Services  effort.  UDDI  was  developed  by  the 
Oasis  Group  [19]. 

Vendors  are  now  supporting  these  specifications  in  their  particular  software  products. 
Currently  available  products  are  capable  of  searching  UDDI  inventories  on  keywords, 
and  returning  matching  services.  Using  the  service  definition  as  described  by  the 
supporting  WSDL,  the  software  will  generate  SOAP  messages  that  can  then  be 
directed  to  the  service. 
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4.3  Cost 


There  is  no  purchase  cost  associated  with  implementing  Web  Services.  However, 
there  will  be  software  development  costs  incurred  to  actually  develop  the  services,  the 
UDDI  listing,  and  the  WSDL  information.  All  of  these  costs  would  be  incurred  in  a 
tactical  data  management  development. 

Commercial  software  products  as  described  in  the  Vendor  section  are  available  starting 
at  about  $200  US. 


4.4  Openness 

Web  Services  are  driven  by  open  standards.  Java  packages  are  also  freely  available  to 
aid  in  the  construction  of  the  services.  Web  Services  can  be  considered  completely 
open. 


4.5  Maturity 

SOAP,  WSDL  and  UDDI  represent  the  core  technologies  of  Web  Services.  The  first 
UDDI  schema  specification  was  created  in  1999.  The  SOAP  specification  was  first 
introduced  in  early  2000.  Finally,  the  first  working  draft  of  the  WSDL  specification 
was  April  2002.  All  can  be  considered  relatively  immature  technologies. 


4.6  Evolution  Potential 

In  a  networked  environment,  Web  Services  have  enormous  potential.  The  ability  to 
create  applications  by  utilizing  remote  services  is  similar  in  concept  to  a  web-based 
function  library  accessible  by  any  development  environment.  However,  there  are 
issues  that  need  to  be  addressed. 

The  following  is  a  small  sample  of  issues  that  will  need  to  be  considered  in  the 
evolution  of  Web  Services.  For  example,  the  security  of  the  transactions  is  presently  a 
problem  and  represents  another  layer  to  the  web  service.  Neither  SOAP  nor  HTTP  is 
capable  of  dealing  with  the  entire  security  issue  [20].  Also,  there  is  reliability  of  the 
service.  A  mission  critical  application  cannot  be  constructed  using  unreliable  services. 
Finally,  the  management  of  the  service  collection  may  require  community 
organization.  If  a  set  of  services  is  to  be  implemented,  who  will  be  responsible  for 
developing  which  service? 
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Although  there  are  numerous  issues  to  be  addressed,  the  development  community  has 
identified  Web  Services  as  an  important  contributor  to  the  next  generation  of  the 
World  Wide  Web.  As  such,  the  evolution  of  Web  Services  is  expected  to  be  high. 


4.7  Overall  Assessment  from  a  Tactical  Data  Perspective 

Web  Services  provide  the  capability  to  separate  applications  into  functional 
components,  and  to  develop  those  components  on  different  platforms,  using  different 
languages,  and  deploy  them  at  different  sites.  In  terms  of  the  management  of  tactical 
data  on  a  single  asset  (e.g.,  submarine),  Web  Services  provide  the  ability  to  integrate 
disparate  tactical  systems. 

This  may  have  application  to  legacy  components  of  a  tactical  system.  The  concept  of  a 
web  service  wrapper,  placed  around  a  legacy  system,  would  open  the  system  to  all 
other  web  service  systems  on  the  local  asset.  In  this  regard,  Web  Services  may  be 
useful  in  integrating  between  existing  disparate  tactical  systems. 

For  any  new  developments  involving  the  integration  of  multiple  tactical  systems  (i.e.,  a 
combat  system),  it  is  unlikely  that  Web  Services  would  play  a  role.  This  is  primarily 
because  the  problems  that  Web  Services  were  developed  to  address  (i.e.,  unknown 
hardware,  unknown  software  languages  and  unknown  interfaces)  are  not  present. 
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5.  Concluding  Remarks 


The  management  of  tactical  data  at  the  single  asset  level  is  a  complicated  problem. 
Multiple  sensors,  creating  multiple  tracks,  assembled  into  a  set  using  multiple  grouping 
algorithms,  with  the  possibility  of  different  classifications,  produces  an  intricate  set  of 
relationships  between  the  data  items.  The  management  of  these  data  represents  a 
considerable  challenge. 

A  combat  system,  which  here  was  loosely  defined  as  a  collection  of  integrated  tactical 
systems,  requires  access  to  the  information  generated  by  all  the  tactical  systems.  In 
this  regard,  the  combat  system  wants  an  unambiguous  view  of  the  data  items,  and  the 
history  of  associations  that  created  these  items. 

In  this  brief  investigation,  three  technologies  were  assessed  for  applicability  to  the 
problem  of  tactical  data  management.  The  LC2IEDM  is  an  army -based  development 
that  applies  to  the  sharing  of  data  in  the  operational  battlespace.  In  this  regard,  the 
LC2IEDM  is  dealing  with  identified  objects.  The  MIST  system  also  deals  with  objects 
as  described  by  the  contact  information  stored  in  the  MIST  database.  Finally,  Web 
Services  provides  a  model  for  developing  shared  service  resources  in  a  networked 
environment,  but  does  not  provide  immediate  benefit  to  the  tactical  data  management 
problem. 

The  three  technologies  were  qualitatively  assessed  relative  to  the  tactical  data 
management  problem  as  outlined  in  the  Introduction.  Unfortunately,  none  of  these 
three  technologies  presently  provide  the  needed  functionality  for  tactical  data 
management.  As  well,  there  is  no  indication  that  the  assessed  systems  intend  to  evolve 
into  the  realm  of  tactical  data. 

Based  on  this  assessment,  the  development  of  a  tactical  data  management  system  is  a 
distinct  possibility.  In  this  case,  it  would  be  advisable  for  any  developed  tactical  data 
management  system  to  consider  the  higher-level  data  sharing  requirements.  For 
example,  in  a  networked  scenario  there  will  likely  be  a  requirement  to  share  the  object 
data  identified  by  the  tactical  systems.  Thus,  it  would  be  advisable  to  consider  the 
C2IS  level  requirements  during  the  development,  to  ensure  some  level  of  compatibility 
between  the  tactical  and  C2IS  levels. 
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Annex  2:  Web  Services  Example 


As  a  web  service  example,  consider  the  Xmethods  site  located  at 
http://uddi.xmethods.net.  Using  specialized  software,  the  Xmethods  site  provides  a 
UDDI  interface  that  may  be  searched  for  keywords.  Searching  the  site  for  keyword 
“temperature”  results  in  one  discovered  service.  This  service  is 
http://developerdavs.com/cgi- 

bin/tempconverter.exe/wsdl/ITempConverter#ITempConverterbinding 

The  temperature  converter  service  provides  a  conversion  between  temperature  values 
in  degrees  Celsius  and  degrees  Fahrenheit.  The  WSDL  that  describes  the  service  is 
shown  in  Figure  6.  The  WSDL  provides  the  specifications  for  a  SOAP  message  that 
would  be  used  for  interfacing  with  the  service.  A  few  of  the  key  WSDL  components 
will  be  described.  For  a  more  complete  description,  see  [21]. 

The  document  element  is  the  <definitions>  tag.  In  the  <definitions>  tag,  is  the  name 
attribute.  The  name  attribute  contains  the  name  of  the  class  that  implements  the 
service. 

The  <message>  tag  is  next,  and  defines  the  information  passed  between  the  client  and 
the  server.  The  <part>  tag  defines  the  message  parameter  using  the  name  attribute. 

As  an  example,  the  “CtoFRequest”  message  has  one  parameter  defined,  that  being  the 
<temp>  element.  This  element  is  defined  by  the  content  of  the  name  attribute  in  the 
<part>  element.  Similarly,  the  response  has  an  element  <return>  defined. 

The  <porttype>  element  describes  the  operations  available  from  the  service.  The 
operations  are  also  linked  to  input  and  output  messages  for  these  operations.  In  this 
example,  two  operations  are  available  as  indicated  by  the  two  <operation>  tags.  The 
available  operations  are  named  “CtoF”  and  “FtoC”  as  indicated  in  the  operation  name 
attribute. 

The  <binding>  element  links  the  defined  operations  to  a  specific  method.  In  this  way, 
all  the  linkages  are  defined.  The  specific  method  is  linked  to  an  operation  (i.e.,  via 
<binding>),  the  operation  is  linked  to  input  and  output  messages  (i.e.,  via  <porttype>) 
and  the  messages  are  linked  to  specific  XML  element  definitions  (i.e.,  via  <message>). 

The  required  SOAP  message  for  this  service  is  shown  in  Figure  7.  The  <temp>  tag 
encloses  the  user  request,  which  in  this  case  is  “1 0”.  The  <temp>  tag  refers  to  the 
temperature  in  degrees  Celsius  that  is  to  be  converted. 

Sending  the  SOAP  message  to  the  service  results  in  the  execution  of  the  service.  The 
service  then  returns  the  SOAP  message  shown  in  Figure  8.  We  see  that  the  return  tag 
encloses  the  value  “50”  indicating  the  returned  temperature  in  degrees  Fahrenheit. 
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<?xml  version^" 1 . 0 " ?> 

<def ini t ions  xmlns="http : //schemas . xml soap . org/wsdl/ " 
xmlns : xs="http : //www . w3 . org/2001/XMLSchema" 
name=" I TempConver ter service" 

targetNamespace="http : / / www . bo r land . com/ soapServices/ " 

xmlns : tns="http : //www . bo r land . com/ soapServices / " 

xmlns : soap="http : //schemas . xml soap . org/wsdl / soap/ " 

xmlns : soapenc="http : //schemas . xml soap . org/ soap /encoding/ "> 

<message  name="CtoFRequest "> 

<part  name="temp"  type="xs : int " /> 

</message> 

<message  name="CtoFResponse"> 

<part  name="return"  type="xs : int " /> 

</message> 

<message  name="FtoCRequest "> 

<part  name="temp"  type="xs : int " /> 

</message> 

<message  name="FtoCResponse"> 

<part  name="return"  type="xs : int " /> 

</message> 

<portType  name=" ITempConverter "> 

<operation  name="CtoF"> 

< input  message^" tns : CtoFRequest " /> 

<output  message^" tns : CtoFResponse" / > 

</ operation> 

<operation  name="FtoC"> 

< input  message^" tns : FtoCRequest " /> 

<output  message="tns : FtoCResponse" /> 

</ operation> 

</portType> 

<binding  name=" ITempConverterbinding"  type="tns : ITempConverter "> 
<soap : binding  style="rpc" 

transport="http : //schemas . xml soap . org/ soap /http" /> 

<operation  name="CtoF"> 

<soap : operation  soapAction="urn : TempConverterlntf- 
ITempConverter#CtoF" /> 

<input> 

<soap:body  use="encoded" 

encodings tyle=" http : //schemas . xml soap . org/ soap /encoding/ " 
name space=" urn : TempConverterIntf -ITempConverter" / > 

</input> 

<output> 

<soap:body  use="encoded" 

encodings tyle=" http : //schemas . xml soap . org/ soap /encoding/ " 
name space=" urn : TempConverterIntf -ITempConverter" / > 

</output> 

</operation> 

<operation  name="FtoC"> 

<soap : operation  soapAction="urn : TempConverterlntf- 
ITempConverter#FtoC" / > 

<input> 
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<soap:body  use="encoded" 

encodings tyle=" http : //schemas . xml soap . org/ soap /encoding/ " 
name space=" urn : TempConverterIntf-ITempConverter " / > 

</ input> 

<output> 

<soap:body  use="encoded" 

encodings tyle=" http : //schemas . xml soap . org/ soap /encoding/ " 
name space=" urn : TempConverterIntf-ITempConverter " / > 

</ output> 

</operation> 

</binding> 

< service  name=" I TempConver ter service "> 

<port  name=" ITempConverterPort " 
binding="tns : ITempConverterbinding"> 

<soap : address  location="http : //developerdays . com/cgi- 
bin/ temp converter . exe/soap/ITempConverter " /> 

</port> 

</ service> 

</def ini t ions > 

Figure  6.  The  WSDL  that  describes  the  temperature  converter  service. 


<?xml  version^" 1 . 0 "  encoding="UTF-8 "  standalone="no" ?> 

<SOAP-ENV : Envelope  xmlns : SOAPSDKl  =  "http : / /www . w3 . org/ 2 0 0 1 /XMLSchema " 
xmlns : S0APSDK2="http : / /www. w3 . org/ 2001/XMLSchema-instance" 
xmlns : S0APSDK3="http : //schemas . xml soap . org/ soap /encoding/ " 
xmlns : SOAP-ENV="http : //schemas . xml soap . org/soap/envelope/ "> 
<SOAP-ENV:Body> 

<S0APSDK4 : CtoF  xmlns : S0APSDK4="urn : TempConverterlntf- 
ITempConverter "  xmlns : xs="http : // www .w3.org/ 2 001/XMLSchema"> 
<temp>10</temp> 

</S0APSDK4 :CtoF> 

</SOAP-ENV : Body> 

</ SOAP-ENV : Envelope> 

Figure  7.  A  SOAP  message  used  to  access  and  execute  a  remote  web  service  that  converts 
temperature  values.  In  this  example,  a  temperature  of  10  TS  is  input  to  the  service. 
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<?xml  version^" 1 . 0 "  encodings ' UTF-8 ' ?> 

<SOAP-ENV : Envelope  xmlnsiSOAP- 

ENV="http : //schemas . xml soap . org/soap/envelope/ " 
xmlns : xsd="http : / /www. w3 . org/ 2001/XMLSchema" 

xmlns : xsi="http : //www . w3 . org/2001/XMLSchema- In stance"  xmlns : SOAP- 
ENC="http : //schemas . xml soap . org/ soap /encoding/ "> 

<SOAP-ENV:Body> 

<NS1 : CtoFResponse  xmlns : NSl="urn : TempConverterlntf- 
ITempConverter "  SOAP- 

ENV : encodings tyle=" http : //schemas . xml soap . org/ soap /encoding/ "> 
<return  xsi : type="xsd: int ">50</return> 

</NSl : CtoFResponse> 

</SOAP-ENV:Body> 

</ SOAP-ENV : Envelope> 

Figure  8.  An  example  output  from  the  temperature  conversion  service.  The  input  shown  in  Figure  7 
is  converted  to  a  temperature  in  Fahrenheit,  50  °F. 
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List  of 

symbols/abbreviations/acronyms/initialisms 


ARM 

Automated  Replication  Mechanism 

ASF 

Apache  Software  Foundation 

ATCCIS 

Army  Tactical  Command  and  Control  Information  System 

C2IEDM 

Command  and  Control  Information  Exchange  Data  Model 

C2IS 

Command  and  Control  Information  Systems 

DBMS 

Database  Management  System 

DND 

Department  of  National  Defence 

DRDC 

Atlantic 

Defence  R&D  Canada  -  Atlantic 

DSTL 

Defence  Science  and  Technology  Laboratory  (UK) 

GH 

Generic  Hub 

HTTP 

Hypertext  transfer  protocol 

LC2DB 

Land  Command  and  Control  Database 

LC2IEDM 

Land  Command  and  Control  Information  Exchange  Data  Model 

MIP 

Multilateral  Interoperability  Programme 

MIST 

Maritime  Information  Sharing  Technology 

NATO 

North  Atlantic  Treaty  Organisation 

NUWC 

Naval  Undersea  Warfare  Center 

OCXS 

Operational  Context  Exchange  Service 

RMP 

Recognized  Maritime  Picture 

SOAP 

Simple  Object  Access  Protocol 

TTCP 

The  Technical  Cooperation  Program 
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UDDI 

Universal  Description,  Discovery  and  Integration 

UK 

United  Kingdom 

US 

United  States 

W3C 

World  Wide  Web  Consortium 

WSDL 

Web  Services  Definition  Language 

XML 

extensible  Markup  Language 
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